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Abstract. Tiie dependency core calculus (DCC), a simple extension of the com- 
putational lambda calculus, captures a common notion of dependency that arises 
in many programming language settings. This notion of dependency is closely 
related to the notion of information flow in security; it is sensitive not only to 
data dependencies that cause explicit flows, but also to control dependencies that 
cause implicit flows. In this paper, we study variants of DCC in which the data and 
control dependencies are decoupled. This allows us to consider settings where a 
weaker notion of dependency — one that restricts only explicit flows — may use- 
fully coexist with DCC's stronger notion of dependency. In particular, we show 
how strong, noninterference-based security may be reconciled with weak, trace- 
based security within the same system, enhancing soundness of the latter and 
completeness of the former. 

1 Introduction 

The dependency core calculus (DCC) [2] is a simple extension of the computational 
lambda calculus [20], where each level ^ in a lattice is associated with a type con- 
structor Ti that behaves as a monad. DCC was designed to capture a central notion 
of dependency common to many programming language settings, including security. 
This notion of dependency is closely related to the concepts of parametricity [22, 29] 
and noninterference [2, 16]. Roughly, DCC's type system guarantees that the computa- 
tional effects of a program protected by some level I can only be observed by programs 
protected by levels I or higher in the lattice. Of course, such effects may include not 
only explicit effects due to data flow, but also implicit effects due to control flow. For 
example, consider the following functions. 

f ~ Xx : Ti{si + S2). bind y = x in y 

g ~ Xx : Te{si + S2). bind y = x in case y of injj(z). (inj^ ()) || \n}2{z)- (inj2 ()) 

The type of the argument x is an ^-protected sum type (si + S2), denoted Tg{si + S2). 
A value of this type is of the form {rje (injj e,)), i G {1,2}, where is an expression of 
type Si, injj is a case constructor, and 1]^ denotes some ^-protection mechanism (which 
can be undone with bind). The function / undoes the protection on x and returns it. 
The function g also undoes the protection on x, but returns only its case constructor. Of 
course, neither function is typable in DCC, since / and g return unprotected results that 
depend on x — in other words, / and g leak information on x. Still, intuitively g may 
seem "safer" than / — while / explicitly reveals all information on x through data flow, 
g implicitly reveals only one bit of information on x through control flow. 
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Traditionally, security experts have dismissed this notion of "safety" as unsound, 
since the attacker might be able to amplify the one-bit leak of information in g to leak 
all information on x, thereby making it as dangerous as /. However, for non-malicious 
code, such attacks are often complex and seem rare in practice [18]. Indeed, in the 
past few years several static analyses for security have focused on restricting effects 
due to data flow, while ignoring other effects [5, 7-13, 19, 25-28, 30, 32, 33, 35]. From 
a theoretical perspective, one may simply consider these analyses unsound, and assume 
that they provide no guarantee. Alternatively, one may try to understand the precise 
guarantee that these analyses provide, and evaluate whether such a guarantee is at all 
important for security. This is the stance we take in this paper. 

Previous work on downgrading and robustness [21, 34] is based on similar concerns. 
Roughly, downgrading allows some specific information in the system to be released, 
and robustness guarantees that this does not cause further, unintentional leak of infor- 
mation in the system. For example, a function p that checks whether a given password 
is correct releases information on the correct password whenever it returns the result of 
the check. A system using p may still be robust, in the sense that the attacker cannot 
exploit the information released by p to leak further information in the system. 

However, downgrading as a mechanism of information release may be too coarse. 
For example, it blurs the qualitative distinction between a usual password-checking 
function that releases partial information on the correct password, and a function that 
releases the correct password itself. (This distinction is similar to the one between func- 
tions g and / above.) In this paper, we explore a finer mechanism of information release, 
called weakening. In particular, weakening the protection on the correct password al- 
lows information on it to be released implicitly through control flow, but not explicitly 
through data flow. As usual, robustness may still require that such weakening does not 
trigger further weakening in the system. 

We study weakening and its properties by considering variants of DCC in which 
explicit and implicit effects are decoupled. The implicit effects arise entirely out of 
case analysis, so the main differences with DCC lie in the handling of sum types. For 
instance, consider the following typing rule in DCC: 

rh e : Tt{s) r,x : s\~ e' : t t is protected at £ 
r h (bind X = e \n e') : t 

The variable x binds the result of e upon undoing its protection. Since x is in the scope 
of e', the computational effects of e' should only be observable to programs that are 
protected by levels £ or higher. This is ensured by the side condition, which restricts t to 
be only of certain forms. (We will review the formal definition of this condition later) 
In particular, t cannot be a sum type, because information on x may be leaked through 
the case constructor of a value of such type. Indeed, this is exactly why / and g are not 
typable in DCC; their results have, respectively, types (si + S2) and (unit + unit). 
In contrast, we study the following typing rule in DCC*, a variant of DCC: 

r h e : Ti{s) r, X : \- e' : t t is weakly protected at £ 
r h (bind X = e\in e) : t 
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The type constructor Tg provides weaker protection than T^; it focuses on restricting 
effects due to data flow, while ignoring other effects. In particular, the side condition in 
the rule above allows t to be a sum type. At the same time, t is adequately restricted 
to ensure that x itself is not released without protection. We introduce open types for 
this purpose; roughly, an open type is given to a value of type s that requires weak 
protection by level I. We assume such a type for x, and prevent t from being an open 
type. In the resulting system, g is typable (after weakening the type of the argument) 
but / is not. We show that if a program is typable in DCC, then it remains typable 
in DCC'' by weakening types. Furthermore, we formalize the precise guarantee en- 
forced by DCC*. This guarantee is related to Volpano's definition of weak security as a 
safety property [31], and it ehminates (at least) Denning and Denning's explicit flow at- 
tacks [14]. For non-malicious code, i.e., code that the attacker cannot fully control, such 
attacks are far more dangerous than implicit flow attacks [23]; thus DCC^'s guarantee 
is important for security of such code, at least from a practical perspective. 

While the typing rules of DCC^ have an interesting flavor of their own, mixing them 
with DCC's typing rules can yield surprisingly pleasant cocktails. We explore a couple 
of such recipes in this paper; they highlight the symbiotic nature of these systems. 

- We study a dynamic weaken primitive that allows values of type Ti to be cast as 
values of type Tg. This weakening may invalidate strong protection guarantees at 
levels t and lower However, weak protection guarantees should still hold at these 
levels, and strong protection guarantees should hold at all other levels. We show 
how these guarantees can be enforced by recycling DCC's types to carry blames 
for weakening. Specifically, we include the rule 

r^e: Tjjs) 
rh weaken e:T^(^)(T£(s)) 

where (3 is some isomorphism from the lattice of levels to some lattice of blames. 
The behavior of the resulting system, DCC'''^, rests on the definition of /3. 

• If /3 preserves joins and meets, then a program's type carries a blame I3{i) such 
that £ upper-bounds the levels of weakening on which its results may depend; 
thus, strong protection guarantees continue to hold at all levels not £ or lower. 

• If /3 exchanges joins and meets, then a program's type carries a blame f3{£) such 
that £ lower-bounds the levels of weakening on which its results may depend; 
thus, weak protection guarantees are robust against all levels not £ or higher. 

- Conversely, we show how a DCC'-style analysis can make DCC's dependency 
analysis more precise. Consider the following functions, which are clearly secure 
yet rejected by DCC because sum types are never considered protected: 

Ax. bind y = x\n (injj ()) i G {1, 2} 

To typecheck such functions, we observe that any information leak is ultimately due 
to either an explicit leak through data flow or an implicit leak through control flow. 
Specifically, evaluating an expression of sum type may reveal information about 
sensitive data only if that expression either does a case analysis on sensitive data, or 
releases the sensitive data itself. We can prevent the former possibility by including 
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a side condition in the rule for case, and the latter by delegating to DCC^'s typing 
rules. We show that the resulting system, DCC^*^, is sound and more liberal than 
DCC; in particular, it admits some new type-preserving optimizations. 

In the context of security, these results suggest some interesting ways in which strong, 
noninterference-based security may be reconciled with weak, trace-based security within 
the same system, enhancing soundness of the latter and completeness of the former 
Specifically, in a system where protection may have been partially weakened, a strong 
blame analysis can be used to provide strong protection guarantees for those parts of 
the system that are not affected by such weakening. Conversely, a weak flow analysis 
can be used to increase the coverage of such guarantees. 

To summarize, we make the following contributions in this paper. 

- We deconstruct DCC, which captures standard information flow, into a weaker sys- 
tem DCC^ that is instead focused on explicit information flow. We argue that this 
system provides the foundations for several recent static analyses for security that 
do not restrict implicit information flow (Section 3). 

- We study a language primitive weaken that switches from DCC-style protection to 
DCC^-style protection of programs at run time. Such weakening may be viewed as 
a milder form of downgrading that preserves data-flow guarantees for the resulting 
programs. Furthermore, we show how such weakening can be controlled by reusing 
DCC mechanisms to associate blames for weakening (Section 4). 

- Going in the other direction, we study how DCC^'s typing rules can enhance the 
precision of DCC's typing rules. This technique (once again) relies on deconstruct- 
ing information flow into explicit and implicit information flow (Section 5). 

We review DCC next (Section 2), deferring further discussion on related work and 
conclusions until the end (Section 6). 

2 Background on DCC 

Recall that the computational lambda calculus [20] extends the simply typed lambda 
calculus with a type constructor that is interpreted as a monad. The monad is used 
to systematically control effects in the language. DCC [2] carries this idea further by 
distinguishing computations at various "levels", and controlling effects across levels. 
Specifically, DCC includes a monadic type constructor for each level in a lattice, and has 
a special typing rule that restricts how computations at various levels may be composed 
based on the lattice. Let I denote levels in such a lattice with ordering join U, meet 
n, bottom ±, and top T. We focus on the following syntax for types and terms in 
DCC. (For brevity, we omit any discussion of pointed types and recursive programs; 
see Section 6 for further comments.) 

types s, t unit | (s ^ i) | (s X | (s + | Ti{s) 
values V () | \x. e | (e, e') | (injj e) | {qg e) 

terms e v \ (e e') | (projj e) | (case e of \n]i{x). ei \\ inj2(a;). 62) | (bind .t = e in e') 
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Types include unit, product, sum, and function types, as well as types r^(s) for 
each level i in the lattice. Terms include the introduction and elimination forms for 
these types; the introduction forms are considered values. In particular, {jji e) has type 
Tg{s) whenever e has type s, and (bind x = {rjg e) in e') reduces to e'[e/x\. 

In practice, rji may represent any mechanism that provides "protection" at level 
broadly construed. In the context of secrecy, for instance, {jn e) may be viewed as an 
encryption of e with a key secret to level The typing rule for bind should then ensure 
that the secrecy of e is preserved in the above reduction. In particular, this may require 
that the result be similarly encrypted. This intuition is captured by a predicate i < t, 
read as "t is protected at €\ meaning that terms of type t cannot leak any information at 
level t — in other words, terms of type t are indistinguishable to any level ^' that is not 
at least I in the lattice. The following rules define this predicate: i < unit; £ ^ (s — 
\^^^<t■,^<{sx t) iff ^ ^ s and l<t;wd(.< Te,{s) iff £ □ f or £ ^ s. 

Significantly, this definition does not consider sum types to be protected. The broad 
reason is that any information in terms is ultimately conveyed by case constructors. 
(The other constructors — unit, tupling, function abstraction, and ^-protection — cannot 
convey any information since they are completely determined by the associated types.) 
For instance, a boolean may be encoded as either ( i nj j ( ) ) or ( i nj 2 ( ) ) , thereby conveying 
one bit of information; so the sum type (unit + unit) can serve as an encoding of the 
datatype boolecin. In general, complex datatypes can be encoded using sum types, and 
the only way of distinguishing terms of such types is by analyzing the case constructors 
used in those terms. Thus, it makes sense to require explicit protection on any term of a 
sum type. (However, we will show in Section 5 that this restriction can be relaxed.) 

The typing rules for DCC derive judgments of the form F; 11 \- e : t, where F 
contains type hypotheses for free variables and 77 is a protection context [29], which 
indicates the maximum level of protection promised by the context. If e is closed, F is 
empty and U is _L, and we use the simpler notation h e : i for the typing judgment. In 
addition to standard rules for the simply typed lambda calculus with sum and product 
types (see the appendix), we have: 

F;nui\-e:s 
F-n^ {'qte):Fg{s) 

.-r.-.N r-n^e:Fi{s) F,x:s;nhe':t t<Tn{t) 

(T-bmd) 

F; n \- bind a; = e in e : t 

(T-ret) states that {r/i e) has type (s) whenever e has type s, assuming ^-protection 
by the context (as promised by joining £ with the protection context). (T-bind) states 
that (bind a; = e in e') has type t whenever e has a type of the form Tg{s), e' has type 
t assuming that x has type s, and the type Tn (t) is protected at i. The latter condition 
means that either t is protected at i, or U is at least £; this ensures that the result of e' 
cannot leak any information at £, including any information on x, which is bound to the 
result of e upon undoing its ^-protection at run time. 

The key property of this type system — ensuring a form of parametricity [22, 29] or 
noninterference [2, 16] — can be formalized using a type-directed indistinguishability 
relation over terms, e ~£ e' : s, meaning that terms e and e' of type s are indistinguish- 
able to level £. In addition to standard rules for logical equivalence (see the appendix), 
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we have that {rji' e) and (77^' e') are indistinguishable to £ unless £ is at least £'. In 
other words, we have that the encryptions of e and e' with a secret key at level £' are 
indistinguishable to an observer at level £ as long as £ does not know any secrets at £'. 

For example, let ei = (77^ (injj ())) and 62 = {rje (injj ())), and suppose that 
£ 2 £'. Then ei 62 : r^(unit + unit). Now recall the functions / and g defined in 
Section 1 (and assume that si = .S2 = unit for simplicity). Then / 7^^/ /, since (/ ei) 
reduces to (injj^ ()), (/ 62) reduces to (injj ()), and (injj^ ()) 7^^/ (injj ()). Similarly, we 
can show that g g. Fortunately, neither function is typable in DCC. Next consider 
/' = Ax. (rji (/ x)) and g' = Xx. {rji {g x)). Then we can show that /' /' : 
T£(unit+unit) — !> Tf (unit+unit) and g' '^i> g' : T£(unit+unit) T£(unit+unit), and 
both functions are typable in DCC. Indeed, the type system guarantees that whenever 
a typed function is applied to ^-protected inputs, it always produces outputs that are 
indistinguishable to levels that are not at least £. 

Theorem 1 (DCC soundness, cf. [29]). If \- e : Ti{s) t, \- ei : s, and h 62 : s, 

then for any £' such that £ ^ £', (e (rji ei)) (e (rji 62)) : t. 

3 Explicit flows and DCC^ 

While DCC can adequately encode various analyses, the underlying notion of depen- 
dency can be overly sensitive in certain settings. In this section, we design a variant of 
DCC with the aim of capturing a weaker notion of dependency — one that is sensitive to 
data dependencies but insensitive to control dependencies. Viewed through the lens of 
information flow, this system restricts only explicit flows of information. We make this 
guarantee precise, and argue why it may be useful for security in practice. 

3.1 Explicit flows 

In their seminal paper on information-flow security. Denning and Denning provided an 
intriguing characterization of explicit flows [14]: "...an explicit flow [of some infor- 
mation X ] occurs whenever the operations generating it are independent of the value 
ofx." Unfortunately, this definition has been largely ignored in the literature. The only 
related work seems to be Volpano's [31], which defines weak security as a trace-based 
(safety) property: a program is weakly secure if its traces induce secure "branch-free" 
programs. We observe that weak security implies the absence of explicit flow attacks, 
since information flows in a branch-free program cannot be generated by operations 
that depend on specific values. (It seems that this connection between Volpano's and 
Denning and Denning's definitions has not been articulated previously.) 

These definitions deserve more attention, since they suggest exactly why explicit 
flow attacks are so interesting in practice. Explicit flow vulnerabilities are attractive to 
attackers, since they can be exploited parametrically. Conversely, such vulnerabilities 
often point to logical errors rather than implementation "artifacts", since the information- 
flow channels are abstract. Finally, various dynamic checks — such as those for excep- 
tion handling and access control — ^routinely cause implicit flows in practice. Ignoring 
these channels not only focuses our attention on other "definite vulnerabilities", but also 
liberates dynamic checks to serve as mechanisms for plugging those vulnerabiHties. 
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This may explain why several recent analyses for security have by design ignored 
implicit flow attacks and focused on eliminating explicit flow attacks [5,7-13, 19,25- 
28, 30, 32, 33, 35]. Some of these analyses aim to verify the security of web applications 
[13,26,28,30]. Many attacks in this context are ultimately due to code injection, and 
a common defense against such attacks is to sanitize values that may flow from inputs 
to outputs. The sanitization mechanisms merely restrict explicit flows — they may well 
introduce implicit flows, but such flows are considered benign in this context. Some 
other analyses aim to formalize security guarantees provided by low-level systems such 
as file and operating systems [4,8,9], which are usually protected by dynamic access 
control mechanisms. Preventing explicit flow attacks with these mechanisms already 
requires some care, and it seems difficult and perhaps undesirable to expect stronger 
guarantees from such systems. 

3.2 DCC* 

Our system, DCC^, is a simple variant of DCC where the type constructors Ti are re- 
placed by Ti, and the protection mechanisms -qi are replaced by rjf . These replacements 
are intended to provide weaker guarantees than their counterparts in DCC, as discussed 
above; we enforce them with a slightly different set of rules, which require a new form 
of type , called an open type. Intuitively, the type is given to terms of type s that 
need to be (weakly) protected at level t. Open types do not have any special intro- 
duction or elimination forms. Instead they qualify existing types [15], according to the 
following equations. 

- {s^Y ~ s^^^ and s = (protection requirements can be joined with U, and any 
type can be viewed as an open type with no protection requirement); 

- unit^ = unit, {s ^ ty = s ^ t^, (s x tf = (s^ x t^), and Tt{sY = Tt'{s^) 
(protection requirements are redundant for the unit type, and can be structurally 
propagated for other non-sum types); 

- Til {sY = Ti' (s) iff I \— I' (protection requirements can be dropped if there is 
adequate protection). 

Note that there is no equation for sum types. In particular, it would be unsafe to 
equate the open sum type (s + tY with the sum type (s^ + t'), for reasons similar 
to those discussed in Section 2. It suffices to see that such an equation would imply 
(unit + unit)^ = (unit^ + unit^) = (unit + unit). But recall that the type (unit + 
unit) can serve as an encoding of boolean; so the equation in question would allow 
protection requirements on booleans to be dropped as needed. In general, this would 
make protection requirements on any data redundant, and completely defeat the purpose 
of open types. Furthermore, note that by viewing the equations above as rewrite rules 
from left to right, it is possible to "normalize" types, effectively pushing the protection 
requirements that occur in those types as inwards as possible. Such normalization helps 
maintain syntax-directed types for most terms, except those that have (open) sum types. 
For the latter terms, we assume that they always have open sum types. 

Our enforcement strategy with open types is rather simple. Upon undoing protection 
of a term of type Ti{s), we give it a type s^. We then demand that such a term be 
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protected back with a level t' that is at least I. The resulting term has type T^/ (s^), which 
can be equated to Tii (s), thereby dropping the protection requirement. To enforce this 
strategy, we define (as in DCC) a predicate i < t, read as "i is weakly protected at 
with the following rules: £ < unit; £ < {s ^ t) iff £ < t; £ < {s x t) iff i < s and 
£<t;£<{s + t)iff£<sand£<t; and£< Tt[s) ifi£ Q£' ox£<s. 

Note that there is no rule for open types, since such types are not protected by 
definition. On the other hand, we include a rule for sum types. Such a rule is sound 
in this context because we are only interested in tracking data dependencies and not 
control dependencies. Indeed, terms of type (s + t) — which evaluate to values (inj^ e) — 
cannot leak any data not already leaked by e (which has type either s or t). In particular, 
the constructors injj cannot leak any data, unless the values (injj e) already require 
protection and thus have a non-trivial open type (where the qualifier is not ±) — which 
is impossible since by the equations above, (s + t) cannot be equal to such a type. 

Following DCC, the typing rules for DCC^ derive judgments of the form F; 11 \- 
e : t, where F contains type hypotheses for free variables and 77 is a (weak) protection 
context. We show only the interesting rules. (The remaining rules are in the appendix.) 



(T°-case) 

(jD-ret) 

(jD-bind) 



F;nh e: {S1 + S2Y T, cc : ; 7J h : s 
F;n \- case e of inj;^(a;). ei || inj2(a;). 62 : s 
F-nu£'r e : s 



F-n^{ri,e):T,{s) 
F;n^ e:Te{s) F, x : s'^;!! ^ e' : t £ <Tn{t) 
F\n V- bind X = em e :t 



(T'^-case) assumes that the case construction (injj e) has an open sum type, and 
propagates its protection requirement to the variable x bound to e at run time. This 
allows sensitive data to be safely destructed, without losing track of its protection re- 
quirements. All other rules are syntax-directed (thanks to normalization of types as 
mentioned above) and are analogous to those in DCC. In particular, (T'-'-ret) states that 
{rj^ e) has type Ti{s) whenever e has type s, assuming (weak) ^-protection by the con- 
text. (T'^-bind) states that (bind 2; = e in e') has type t only if e has a type of the form 
Ti{s), e' has type t assuming that x has open type s^, and the type Fjj{t) is (weakly) 
protected at £. The latter condition means that either t is protected at £, or n is at least 
£. This ensures that the result of e' cannot leak any data at £, including any data in x, 
which is bound to the result of e upon undoing its ^-protection at run time. 

We formalize the key property of this type system using a type-directed safety re- 
lation over terms, e t>i : s, meaning that term e of type s is safe at level £. Our 
safety relation relies on a semantics with "taint propagation". Thus, we extend the 
internal syntax with terms of the form e^, meaning e tainted with £ — intuitively, 
is similar to (bind x = (^^ e) in x) for fresh x. We define equations over tainted 
terms, closely following the equations over open types. Thus we have; [e^Y ~ e^^^' ; 
e - e\ (Y - 0; (Ax. eY - Xx. e^; (61,62)^ = {elei); {rj,, eY = (% e'); 
and (77^, eY = {rji' e) iff £ C £'. As usual, these equations let us normalize terms 
so that only terms of sum types carry taints. Finally, we extend the local reduction 
rules for bind and case as follows: (bind x — {rj^ e) in e') reduces to e'[e^/x], and 
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(case (injj e) of injj^(x). ei || inj2(a;). 62) reduces to ei\e^ lx\. Thus, we taint a term 
upon undoing its protection, and propagate the taint on a term to its subterm upon 
pattern matching. Note that such taint propagation ignores implicit flows. We use this 
semantics in the derivation rules of our safety relation, as follows. 

- e l>f : s iff e reduces to v and u : s 

- ()[><?: unit 

- w l>f : (s — > t) iff for all e, if e l>£ : s then (v e) \>e : t 

- (61,62) \>e ■ (si X S2) iff 61 \>e ■ si and 62 \>e ■ S2 

- (injj ei) l>e M^si + S2) iff Of : Si 

- {rjg, e) \>i : Tt{s) iff I' g fore : s 

Thus, safety is analogous to indistinguishability as defined in Section 2, except that 
we are concerned with properties of a single term rather than a pair of terms. As ex- 
pected, tainted terms are unsafe, and (jy^, e) is safe at t unless £ is at least i' . 

For example, let e = {rj^ (injj ())) for some i e {1, 2} and suppose that I i' . 
Then e \>ii : (unit + unit). Now recall the functions / and g defined in Section 1 
(and assume that si = S2 = unit for simplicity). Clearly / />^,, since (/ e) reduces to 
(injj 0)^ and (injj ()) />g,. Fortunately, / is not typable in DCC''. In contrast, we can 
show that g t>i' : r^(unit + unit) (unit + unit), and g is typable in DCC''. Next 
consider /' = Xx. (rj^ (/ x)). It is easy to check that /' l>£' : Ti{un'\t + unit) — >• 
T^(unit + unit), and /' is typable in DCC*. Indeed, the type system guarantees that 
whenever a typed function is applied to (weakly) ^-protected inputs, it always produces 
outputs that are safe at levels that are not at least £. 

Theorem 2 (DCC' soundness). If he: Te{s) — > t and h e' : s, then for any i' 
such that I % I', (e e!))\>ej -.t. 

Furthermore, we show that DCC^'s type system is at least as liberal than DCC's, by 
defining an appropriate encoding between the two systems. (In fact, it is strictly more 
liberal by the example above.) 

Theorem 3 (DCC to DCC^). Let |-] translate terms and types by replacing •) with 
{rjf ■), and (•) with Te{-).If\-e:s in DCC then h |e] : {sj in DCC^. 

3.3 Remarks 

Before we move on, let us try to carefully understand the guarantee provided by DCC^. 

Deck's semantics, based on taint propagation, is closely related to Volpano's exe- 
cution monitor for weak security [31]. In fact, results of evaluation in DCC'' can be in- 
terpreted as branch-free DCC programs "induced by traces", and typing in DCC* guar- 
antees security of such programs in DCC. 

Theorem 4 (DCC* soundness, a la Volpano [31]). Let \ translate terms and types 
by replacing {rjg ■) with •), Ti{-) with Ti{-), and (•^) with (bind x = •) in x) for 
fresh X. If h e : Ti{s) ^ t, he': s, and (e {rjf e')) evaluates to v in DCC^, and if 
no protection type occurs negatively in t, then \^ : in DCC. 
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For example, consider the following function of type Ti{un\t + s) — (unit + (s)): 

k = Xx. bind y = x \n case y of injj(z). (injj ()) || inj2(2:). (injj (7/^ z)) 

Let e be any term of type s; we have that {k {jj^ (injj e))) reduces to (inj2 {fji e*")), 
which translates via to (inj2 bind = {r]i e) in w)). The latter is a branch-free, 
typed, DCC program. In fact, by the theorem above, all branch-free programs induced 
by traces of k are typed, and thus k is weakly secure. In contrast, if the protection (jj^ ■) 
in the body of k is dropped, the induced branch-free program does not remain typable. 

Furthermore, DCC's type system eliminates explicit flow attacks as characterized 
by Denning and Denning [14], since we have already argued that weak security implies 
the absence of such attacks. Note that an explicit flow attack can be camouflaged as an 
implicit flow attack by "deep copying", i.e., by destructing a sensitive term all the way 
down with elimination forms and constructing it back from scratch with introduction 
forms. Formally, let erase be a function on types that erases the label qualifiers in open 
types. Thus, for any s, we have I < erase(s) for all £; in other words, the side condition 
in (T'-'-bind) is redundant for erased types. Now we can define a family of functions 
leake{t) : Ti{i) erase(t) that behave just like Aa; : Tg{t). bind y = x \n y, such 
that the former are typable in DCC'', but the latter are not (see the appendix). Thus, 
in the limit we may be assured nothing even if DCC'' deems our program "secure" — 
while DCC* guarantees that all explicit leaks are eliminated, these leaks may remain 
hidden in the guise of implicit leaks (which remain unrestricted). However, we argue 
that DCC'' still provides "pretty good protection", at least for code that the attacker 
cannot fully control. Indeed, for such non-malicious code, we may assume that the pro- 
grammer does not try to intentionally circumvent our analysis. Under this assumption, 
prioritizing expUcit flows over implicit flows is arguably reasonable, for several reasons: 

- No sane programmer would copy all bits of some value indirectly, one at a time, 
instead of copying the value directly. 

- As argued in [23], implicit leaks are largely harmless for non-malicious code, since 
such leaks cannot be exploited efficiently by the attacker. 

- As shown in [18], checking for implicit flows can be costly to the programmer — 
typically lots of false alarms arise in systems that check for implicit flows. 

4 Dynamic weakening in DCC'''^ 

While DCC'-style protection is sufficient in some settings, DCC still enjoys better the- 
oretical foundations and promises many desirable properties that DCC'' cannot. In prac- 
tice, we should be able to mix DCC'-style protection carefully with DCC-style protec- 
tion as needed, and still be able to reason precisely about the guarantees of the resulting 
systems, short of weakening all the guarantees provided by DCC-style protection. We 
investigate these issues in the setting of a hybrid language DCC'''^. 

4.1 DCC'''^ 

DCC'^'^'s syntax and typing rules are obtained by merging those of DCC and DCC*. 
The merge is mostly straightforward; we make a few adjustments to encourage the two 
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subsystems to interact. (The full system is available for reference in the appendix.) 
First, we carry both kinds of protection contexts in typing judgments, and modify the 
DCC rule (T-ret) as follows. 

r;nu£;nuih e : s 
r-n-nh{r,te):T,{s) 

Thus, any DCC-style protection provided by the context is made evident not only in 
its usual protection context, but also in the weak protection context. Next, we add the 
following protection rules and open type equations: £ < Tg'{s) if £ < s\ £ < T(i{s) 
if £ < ft{s); and Tt{sY = Tt,{s^) \fTt{sY = ft{s^)- These rules internalize 
the fact that DCC's protection types subsume DCC^'s protection types, as shown in 
Theorem 3. In particular, these rules admit functions such as \x. bind y ^ x'm (rji y) 
of type Te{s) Ti{s), that can be used to strengthen protection on terms. Finally, we 
unify the rules for non-protection types; in particular we have: 

/-tDC r;77;iThe: (.S1 + S2/ a; : 4; 77; TT h e, : s 

(T -case) = 

7^; 77; 77 h case e of in]^{x). ei \\ inj2(a;). 62 : s 

The definitions of indistinguishability and safety are similarly extended, and we can 
show that the respective guarantees of DCC and DCC^ are preserved in DCC'''^. 

Theorem 5 (DCC'''^ soundness, preliminary). Theorems 1 and 2 also hold in DCC'^'^. 



4.2 A weakening primitive 

Next we include a weaken primitive in DCC'*'^, which acts as a further bridge between 
the two subsystems (going in the opposite direction as the strengthening functions 
above). Our intention is that such a primitive should allow terms of type Ti{s) to be 
viewed as terms of type Ti{s), possibly with some caution. 

Unsurprisingly, using weaken may invalidate the protection guarantees provided by 
DCC's types. As a simple example, consider the following function: 

h = \x. bind y = (weaken x) in case y of inj]^(z). (injj ()) || \r\i2{z). (injj ()) 

Assuming a typing rule that allows (weaken e) to have type Ti{s) whenever e has 
type Ti{s), this function can be typed Ti{un\t + unit) — > (unit + unit). However, h 
clearly has an information flow violation; formally, we have that {h {rji {\n]^ ()))) 7<i^ 
{h {rji (inj2 ()))), which contradicts Theorem 5. Worse, h can be used as an oracle to 
generate more complex counterexamples. Consider the following functions: 

m = Xx. (rje (bind y ~ x in case y of injj(z). (inj^ ()) || \n]2{z). (injj ()))) 
n = Xx. {h (m x)) 

The function m can be typed Tei{s+t) — > r£(unit + unit) in DCC as long as £' C £, and 
does not leak information on x per se; it derives a bit of information on x and protects 
that bit before returning it. Still, the function n with type T^/ {s + t) — > (unit + unit) is 
able to use m in combination with h to leak that bit. 
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As this example suggests, using wea ken at level ^ in a program may invalidate DCC- 
style guarantees for all types protected by levels i and lower However, weaker DCC*- 
style guarantees should still hold for such types (because there is no way to get around 
Deck's typing rules). Moreover, assuming that there are no other uses of weaken in 
the program, we expect that stronger DCC-style guarantees should remain valid for 
all other types. The reason is that such types, which are protected by levels higher or 
incomparable to £, will never delegate the responsibiUty of protection to the weakened 
types. In summary, we can precisely reason about protection in this system as long as 
we carefully track the uses of weaken in the program. 

Curiously enough, such an analysis can be viewed as a special case of DCC's de- 
pendency analysis, just like many other applications of DCC. Indeed, the original moti- 
vation for studying DCC was its ability to express various program analyses — including 
call tracking, slicing, partial evaluation, as well as information-flow control — in a uni- 
form setting. Our analysis is similar in spirit, and can be expressed by recycling DCC's 
types to carry blames for weakening. 

Specifically, we consider a lattice of blames that is isomorphic to the lattice of levels, 
i.e., for each level £ we have a blame /?(£), where /3 is some lattice isomorphism. Then, 
instead of the naive typing rule for weaken above, we include the following rule: 

(T -weaken = = 

T; iJ; 77 h (weaken e) : T^(f)(r£(s)) 

Intuitively, this means that whenever we use weaken to view terms of type T^(s) as 
terms of type Tt{s) in a program, we simultaneously blame for facilitating such 
a view. While this allows us to get away with weaker protection requirements on such 
terms, it also forces some caution: the blame must be carried around whenever a result 
depends on those terms. Fortunately, DCC's typing rules can enforce this for free. 

A reassuring interpretation of blames may be obtained through the lens of the Curry- 
Howard isomorphism, following a recent reading of DCC as an authorization logic [1]. 
Specifically, we can interpret the blame j3{€) as a principal that controls protection 
requirements at level and rewrite the type of (weaken e) as /?(£) says {Ti{s)). Using 
the logic, we can now pinpoint the principals whose statements may have influenced 
protection requirements in a program, resting assured that the protection guarantees at 
other levels will not be influenced by these statements. 



4.3 Blame orderings 

Note that we have not yet specified how the ordering in the blame lattice should be 
related to One interesting scenario is where the ordering is the same, so that /3 pre- 
serves joins and meets. In this scenario, the type of a program must carry a blame /3{£) 
such that £ upper-bounds the levels of weakening on which its results may depend. (This 
is because DCC's rules guarantee that /3{£) will upper-bound the levels of weakening 
on which the results of the program may depend.) In other words, DCC-style protection 
guarantees must hold at all levels not £ or lower. 

Formally, we define the blame B{t) carried by a program of type t as the join of all 
blames that appear in t. We then prove the following theorem. 
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Theorem 6 (DCC^'' soundness: strong protection). //^ \- e : Ti{s) ^ t, h a : s, 

h 62 : s, and £ is any label such that £ % l3^^{B{t)), then for any £' such that £ % £', 
(e (77^ ei)) (e {t]i 62)) : t. Moreover, Theorem 2 holds as is in this system. 

As a simple example, consider the following well-typed program of type T^(£)(unit + 
unit) (where i £ {1, 2}): 

bind X = (weaken (ry^ (inj^ ()))) in {■qp(i) x) 

We have ;B(T^(£)(unit + unit)) = P{£), so we can be sure that this program does not 
(and cannot be used to) weaken DCC-style protection guarantees at £' unless £' □ £. 

An equally interesting scenario is where we flip the ordering in the blame lattice, so 
that /3 exchanges joins and meets. In this scenario, the type of a program must carry a 
blame /?(£) such that £ lower-bounds the levels of weakening on which its results may 
depend. (Again, this is because DCC's rules guarantee that I3{£) will upper-bound the 
levels of weakening on which the results of the program may depend.) In other words, 
DCC^-style protection guarantees must be robust against all levels not £ or higher 

Formally we prove the following theorem, where B{t) is defined as earlier. 

Theorem 7 (DCC'''^ soundness: weak protection). Suppose that h e : Ti{s), h e' : 
Te{s) t, and £ is any label such that /3~^{B{t)) % £. Then it is impossible to derive 
h (e' (bind x = (weaken e) in x)) : t. 

Continuing the previous example, we can be sure that DCC'-style guarantees for the 
program are not influenced by weakening at level £' unless £ \Z £'. 

5 Precise dependency analysis in DCC'^ 

Just as a DCC-style analysis can strengthen protection guarantees in a hybrid system, 
in turns out that a DCC'-style analysis can improve the coverage of such guarantees. 
In this section, we deconstruct information flow control in DCC into two separate prob- 
lems: one of restricting explicit flows, and the other of restricting implicit flows. The 
former is already handled by DCC*; the latter, which is entirely due to case analysis, 
can be handled by reworking some of the rules for sum types in DCC. The resulting 
system, DCC^'', becomes more liberal than DCC without compromising its guarantees. 
We discuss the benefits of such an enhancement towards the end of the section. 

5.1 DCC'^'^ 

DCC conservatively assumes that case constructors may always convey sensitive infor- 
mation; thus, it restricts both explicit and implicit flows in one shot by requiring that 
sum types can never be considered protected (see the discussion on DCC's protection 
rules in Section 2). Unfortunately this restriction causes several benign programs to be 
rejected by DCC simply because they use case construction. We relax this restriction by 
observing that any information leak is ultimately due to either an explicit leak through 
data flow or an implicit leak through control flow. Specifically, evaluating a term of 
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sum type may reveal information about sensitive data only if that term either does a 
case analysis on sensitive data, or releases the sensitive data itself. 

Technically, this separation of concerns is already somewhat evident in DCC^, 
where we weaken DCC's protection rules to allow sum types to be considered pro- 
tected (see Section 3). But by itself this is unsound, given the dangerous nature of case 
constructors — it admits both explicit and implicit flows. Thus, we also require open 
types — types with qualifiers to precisely track data flow through programs — and we 
use these qualifiers to restrict explicit flows in DCC*. In particular, the typing rule for 
case analysis needs to accommodate terms with qualified sum types, because the qual- 
ifiers can be eliminated on all types other than sum types — they "stick" to sum types 
exactly because of the dangerous nature of case constructors. While in DCC' we choose 
to ignore implicit flows caused by such case analysis, in DCC'^'' we do not. 

Note that in order to adjust the rule for case analysis to account for implicit flows, we 
must have some idea of the level of information that we are interested in protecting — 
otherwise, we would have to conservatively ban any case analysis. For this purpose, we 
need to carry an open context S in typing judgments, which indicates the minimum 
level of protection required by the context. For closed terms, S is T. 

The developments of Section 4 are orthogonal to our present purposes, so we drop 
terms of the form (weaken e) and (77^ e) in the language; indeed, on the surface we do 
not care about DCC'-style protection at all, although DCC^'s type system is an im- 
portant component of the system internally. Accordingly, we also drop weak protection 
contexts. The remaining system mostly inherits from DCC'''^; we make a few adjust- 
ments, discussed below. (The full system is available for reference in the appendix.) 

We now have two typing rules for bind, both offering DCC-style protection. The 
first rule is similar to that in DCC. 

r-n-S^e-.Tiis) r,x : s;n;Sh eJ -.t £^Tn{t) 

(T^°-bind-old) r;n;Sh- bind x = e\ne' -.t 

The other rule is new, and captures the interaction of the two subsystems. 

r;n;Sh e:Te{s) r, x : s*^; H; S H £ h e' : t £<Tn{t) 
(T'^°-bind-new) r; 77; h bind x = e\r\e -.t 

Curiously, this rule looks similar to (T'-'-bind) in DCC^, although functionally it is 
intended to be closer to (T-bind) in DCC. Like (T-bind), (T'-'-'-bind-new) applies to 
terms of type Ti{s) instead of Ti{s). On the other hand, like (T'-'-bind), we use the 
weak protection predicate < instead of ^, while assuming an open type for x. This 
takes care of explicit flows, but not implicit flows. In addition, to handle implicit flows, 
we meet t with the open context, deferring their actual restriction till we encounter case 
analysis at level £. 

The new rule for case analysis is as follows. 

r;7T;^|-e: (si + ss)^ r,x : s^- H] S ^ ei : s 

(T'-'-'-case) F; U; S \- case e of \r\}i{x). ei || inj2(a;). 62 : s 

As in (T'-'-case), this rule requires — without loss of generality — that e have an open 
sum type, with some protection requirement £. In addition, it requires that the open 
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context S be no lower than £ — so that any implicit flows at £ that may occur through 
the case analysis are irrelevant to [i.e., cannot compromise) S. With these rules, we 
show that DCC^'^ provides the same guarantees as DCC, and is at least as liberal. 

Theorem 8 (DCC'^'^ soundness and completeness). If ^ e : Ti{s) ^ t, h ei : s, 
and h 62 : s, then for any £' such that £ % £' , (e (jj^ ei)) (e [rj^ 62)) : t. 
Furthermore, ifhe' : s' in DCC then h e' : s' in DCC'^'^. 

In fact, DCC '^'^ accepts more programs than DCC. For example, the following functions — 
rejected by DCC (see Section 1) — have type Ti{s) (unit + unit) in DCC'^'': 

A.T. bind y ^ X \n (injj ()) i e {1, 2} 

As a more interesting example, consider the function switch below — ^rejected by DCC — 
which has type (boolean) — > boolean — !> option(T^(boolean)) in DCC'^''. (We 
use the encodings boolean = (unit + unit), option(a) = (unit + a), false = 
(injj ()),true = (injj ()), (if ethene2 elseei) = (case e of inj;^(_). ei || inj2(-). 62), 
none = (inj^ ()), and (some e) = (inj2 e). 

switch = A.T. \b. bind 6' = a; in {{match h) h') 
match = Xb. Xb' . if b then none else (some {rjg {not b'))) 
not ~ Xb' . if b' then false else true 

In general, undoing protection of terms early in the control-flow graph seems to cause 
problems in DCC, but not in DCC'^''. 

5.2 Remarks 

One may, of course, wonder whether our enhancement of DCC's type system is at all 
necessary. Indeed, DCC is designed to be a target language in which (type-based) pro- 
gram analyses can be encoded to prove their soundness: typing derivations in the source 
language are translated to typing derivations in DCC, and the soundness of the latter is 
used to reason about the soundness of the former In this sense, in fact it is possible 
to encode DCC^*^ in DCC: we compile DCC'^'' programs to the SLam calculus [17] 
by erasing binds, and then use the well-known encoding of SLam in DCC [2]. Thus, 
DCC's status as a core calculus of dependency is not challenged. However, as in most 
such encodings, the translated DCC programs are not syntactically equivalent to the 
source programs. In particular, binds may be pushed inwards and duplicated across 
branches. Reasoning about the soundness of this translation requires exactly those ob- 
servations that underlie the design of DCC^''. Furthermore, the translated programs are 
inefficient. Indeed, in implementations of DCC in the polymorphic lambda calculus 
[29], binds are implemented as applications of secret keys (decryptions) to protection 
abstractions (encryptions) — and it makes sense to pull such applications as outwards as 
possible for efficiency. For source languages with DCC-like primitives, it is reasonable 
to expect that programs will be already be optimized; and we have shown that DCC-like 
typing rules do not preserve typability for such optimizations. In summary, we believe 
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that deconstructing information-flow analysis into explicit-flow and implicit-flow anal- 
ysis, as in DCC'^'', provides a better guideline for designing type systems for DCC-like 
source languages, than placing an overall restriction on sum types, as in DCC. Other 
enhancements along such lines have been suggested previously [29]. 

6 Discussion 

For brevity, in this paper we have omitted any discussion of pointed types and recur- 
sive programs, although they do appear in DCC [2]. However, we have checked that 
including these elements does not cause any problems in our results — which is hardly 
surprising since nontermination does not play an interesting role for weak security. 

We have tried to remain close in spirit to Volpano's definition of weak security and 
Denning and Denning's characterization of explicit flows in our formal definition of 
DCC^. However, inherent differences in the underlying languages make it difficult to 
establish a formal correspondence. 

There is a huge body of research on noninterference-based security for languages; 
see [24] for a survey. However, there seems to be a disconnect between this research 
and most security tools implemented in practice, which ignore implicit flows. Some 
interesting previous studies have tried to explain why, and under what circumstances, 
it may make sense to ignore implicit flows in practical security [18, 23]. Unfortunately, 
we do not know of any work on formalizing the resulting safety guarantees of such 
tools, although [31] provides some valuable insights and several security type systems 
for process calculi have been designed around similar ideas [3, 6, 8, 9]. 

The idea of mixing strong and weak dependency analysis in mutually benefitial 
ways appears to be new. Indeed, our results suggest some interesting ways in which 
noninterference-based security may be reconciled with trace-based security within the 
same system, enhancing soundness of the latter and completeness of the former Specif- 
ically, in a system where protection may have been partially weakened, a strong blame 
analysis can be used to provide strong protection guarantees for those parts of the sys- 
tem that are not affected by such weakening. Conversely, a weak flow analysis can be 
used to increase the coverage of such guarantees. 

We hope that these results will spur further interest in bridging the gap between 
these two views of security. 
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Typing rules (DCC) 



(T-var) r,x : s, F'; 11 \- x : s 

(T-unit) r;i7h():unit 

, , r, X : s; 77 h e : t 

(T-abs) 

(T-app) 

(T-pair) 

(T-proj) 

(T-inj) 

(T-case) 

(T-ret) 

(T-bind) 



T; 77 h Aa;. e : (s ^ t) 
r;n\-e:s^t T; 77 h e' : s 

r;77 h (ee') : t 
r;77hei:si T; 77 1- 63:52 
r;77 h (61,62) : (si x S2) 
r;77 h e : (si X S2) 
r;n\- (projj e) : Si 
r;77 h e : Si 
r;77h (inj, e) : (si + S2) 
T; 77 h 6 : (si + S2) T, a; : s;; 77 h 6; 
r-. nV- case 6 of inji(a;). ei || inj2(a;). 62 
r:77U^ h e : s 



r;n\- e:Te{s) F, x : s; H \- e : t e^Tn{t) 
F: n \- bind x = e\n e : t 



Indistinguishability relation (DCC) 



l-unit) 
l-function) 

l-product) 

l-sum) 

l-monad-1) 

l-monad-2) 

l-eval) 



~f : unit 

V6, e . e r^e e' : s => {v e) (v' e) : t 
V v' : {s ^ t) 
61 r^i e'l : Si 62 ~f e'2 : S2 
(61,62) ~£ (e'l, 62) : (si X S2) 

6; ~£ 6 ■ : S i 

(inj. ei) ~£ (inj. e'i) : (si + S2) 
£' ^£ 

iVe' e) (r^f' e') : Te,{s) 
I 

6 ~£ 6 : s 



e) (?7^/ e) : Ti,{s) 

* f * f t 

■ V 6 — )■ V V V : s 



e e -.3 
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Typing rules (DC&) 



(T°-var) r,x : s,r';n \- X : s 

(T°-unit) ^ ^ : unit 

(T°-abs) r,.:.;77he:t 

(T°-app) 
(T°-pair) 
(jD-proj) 
(T°-inj) 
(T'^-case) 
(T°-ret) 
(T°-bind) 



r;77 h As. e : (s ^ 
r;T[ \- e : s ^ t F;!! \- e' : s 

r;n\- (e e') : t 
r:7j \- ei : si r-U h e2 : S2 
r-n\- (61,62) : (si X S2) 
T; i7 h e : (si X S2) 
r;77h(proj, e):sO 
T; 77 h e : Si 
r;77h (inj, e) : (si + S2) 
i^; 77 h 6 : (si + S2Y r,x : s{\ U \- ei : s 
r;n \- case 6 of injj(a;). ei || inj2(a;). 62 : s 

r-.nui}- e : s 



r;77h6:Tf(s) r,x : -Tl h e : t l <Tjj{t) 
r\n \- bind a; = 6 in 6' : f 



Leaking explicit flows via implicit flows: DCC* 



leakiiumt) = \x : (unit). () 
leaki{s X t) = Xx : Ti{s x t). bind y = 2: in 

{leake{s){rii, (proji y)), leake{t){rji (projj y))) 
leaki({a + t)^') = Aa; : Tt{{s + tY'). bind y = x\n 
case y of 

inji(2i)- (inji {Ieakiue'is)irjeut' zi))) 
|j_inj2(z2). (inj2 {leakiui'{t){rjeue' ^2))) 
leaki(a t) = \x : Ti{s t). 

\z : s. bind / = a: in leake{t){r]i (/ 2)) 
leaki{T II (a)) = Aa; : Te{Tti{s)). bind y = x\n 
{rjf,, {leaki, {s)y)) 
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Syntax: DCC 



types s,t::= unit \ {s X t) \ {s + t) \ (s ^ t) \ Ti{s) \ Te{s) \ s' 
terms e, v ::= () | (e, e') | (proj^ e) | (inj^ e) | case e of injj^(a;). ei || inj2(a;). 62 
Aa;. e j (e e') | {rje e) \ {fj( e) | bind x = e\n e' \ (weaken e) 



Typing rules: DCC* 



(T°<^-var) 
(T°^-unit) 

(T°'^-abs) 
(T°^-app) 



(T°^-pair) 



(T^'^-proj) 



(T°^-inj) 



(T^'^-case) 
(T°^-ret-l) 
(T°^-ret-2) 

(T°'^-bind-l) 

(T°^-bind-2) 
(T°'^-weaken) 



r,x : s, r'; n;n\-x:a 
r;n;n\- () : unit 
r,x : s;77;77 h e : t 

r;77;77 h Aa;. e : {s ^ t) 
r;n;ll\- e: s r;i7;77he':s 

r-n-n\- (ee) -. t 

r;i7;77 h ei : si T; il; 77 h e2 : S2 
r;i7;77h_{ei,e2> : (si x S2) 
T; J7;77 h e ; (si X S2) 

r;i7;77f-_(proj, e) : 
T; i7; i7 h e : s, 

_ r;i7;77l- (inj, e) : (si + S2) _ 
F; 17; n \- e : (si + 32)^ r,x : sl\ U; U \- ei : s 

r;n;n\- case e of injj(a;). ei || inj2(a;). 62 : s 
r;i7U^;77u^ h e : s 

r-n-n^{T,ee) -.Teis) 
r:n:n Ulh e : s 



r:n:n\-e 



TAs) r,x : s;n;n\- e 



t l<Tn{t) 



r;n;n\- bind 3; = e in e' : t 
r-n-lT\- e:Ti{s) R x : s^; n-Jj \- e : t £<Tn{t) 

r;n;n\- bind x — e \n e : t 
r;n;nh e: Ti{s) 



r-n-nV- (weaken e) : T^(,)(r,(s)) 



Protection rules: DCC* 



1 

(P-unit) 


£ ^ unit 








1 


(P-product) 




A < 


' ^ t ^ 


l<{a 


X t) 




(P-function) 


I ^ t 




£ ^ (s - 


^t) 






(P-monad-1,2) 


e^i' 






is) , 


£^s ^ 


£^Tt,{s) 


(P-effect) 


£^s 






(s) 






(P°-unit) 
(P°-product) 


£ < unit 










£<s 


A t 




l<(a 


X t) 




(P°-function) 


I < t 




£<(s- 








(P°-effect) 


£\Zl' 




£<Te 


is) , 


£< s ^ 


£<Te,{s) 


(P°-sum) 


e<s 


A £ < t ^ 


£<{s 


+ t) 




(P°-monad) 

■ 


£<T 


r(s 


) l<Te{s) 
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Open type equations: DCC* 



(E-open-1,2) {s'Y ^ s'""' , s = 

(E-unit) unit^ = unit 

(E-product) (s X tY = (/ x t^) 

(E-function) {s ^ t)^ = s ^ 

(E-effect-1, 2) Te, {sY = T^, (s*) , I ^ i' ^ Te, {sY = Te, (s) 

(E-monad) Ti,{sY =Te,{s') => T^, {sY = T,, {s') 



Syntax: DCC^ 



types s,t :■- unit \ {s x t) \ {s + t) \ {s ^ t) \ Ti{s) j Te(s) \ 
terms e, v ::= () | (e, e') | (proj^ e) | (inj^ e) | case e of injj^(a;). ei || inj2(a;). 62 
I Xx. e I (e e') | (77^ e) | bind x — etn e' 



Typing rules: DCC" 



(T^°-var) r,x : s,r'-n-i; h X : s 

(T^°-unit) r;i7;X' h : unit 

r,x : s;n-E h e -.t 



(T^°-abs) 



(T^°-app) 
(T^°-pair) 
(T^°-proj) 
(T^°-inj) 



r;7T;i: I- Xx. e : {s ^ t) 
r-n-Ehe:s^t r;n;E\-e':s 

r-n-Sh (ee) : t 
r-n;E\-ei:si F; H; E \- e2 : S2 
r-n;Sh (ei,e2> : (si x sa) 
T; 77; rh e : (si X S2) 

r;n;S\- (proj . e) : Si 
r-n-E\-e:Si 

r-n-Eh (inj, e) : (si + S2) 
r;77;X' h e : (si + S2)^ ^ g ± ^ X" g ^ T, x : s • ; 77; T h : s 



(T'^'^-case) 7^; 77; X" h case e of injj^(a;). ei || inj2(2;). 62 : s 

CD r;nu^;i:he:s 
" r;7r;rh (»7«e) :Tf(s) 

r;n;i:\-e:Ti(s) F, x : s; U; E \- e : t l^Tnit) 

(T^°-bind-l) r-n-EV- bind x = eme -.t 

r;n;E^ e:Ti{s) r,x : s'^; H; E H £ h e : t £<Tn{t) 
(T'=°-bind-2) r; 77; X" h bind x = e in e' : f 



Protection rules and Open type equations: DCC^"^ 
I 

Same as those for DCC*". 
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